Elasticsearch et Kibana sont les deux produits phares de la société Elastic. Le premier est un moteur de base de données dédié à la recherche, le second un tableau de bord, permettant notamment de visualiser les données dans Elasticsearch.
Les deux produits étaient initialement open source. En 2021, changement radical : les licences open source sont abandonnées. Shay Banon, fondateur et directeur technique, explique alors dans une annonce que la bascule est une conséquence du « comportement inacceptable d’Amazon » depuis 2015. L’objectif était d’empêcher les entreprises – et surtout Amazon – de fournir directement Elasticsearch et Kibana sous forme de services, sans collaborer avec Elastic.
En avril 2021, Amazon a finalement créé son propre fork d’Elasticsearch, nommé OpenSearch. « Amazon s'investit pleinement dans son fork, la confusion sur le marché a été (en grande partie) résolue et notre partenariat avec Amazon Web Services est plus fort que jamais », a écrit Bannon le 29 août.
Dans cette annonce récente, le fondateur se dit « heureux » de pouvoir annoncer le retour d’Elasticsearch et Kibana à l’open source. Plus précisément, sous licence AGPL, conçue pour les produits de serveur, avec obligation de publication sous la même licence pour toute modification apportée au code.
Il ne s’agit pas d’un retour à la situation antérieure à 2021. La licence AGPL sera une nouvelle option aux côtés des actuelles (ELv2 et SSPL, non reconnues comme open source).
Cette annonce ayant relancé les discussions sur les tensions qui ont pu exister avec Amazon, des points de vue contradictoires sont apparus. Adrian Cockcroft, ancien vice-président d’AWS, s’est ainsi exprimé sur Hacker News. Selon lui, « AWS voulait apporter des fonctionnalités de sécurité au projet open source et Elastic voulait maintenir la sécurité en tant que fonctionnalité d'entreprise, rejetant ainsi toutes les approches d'AWS à l'époque ».
Commentaires (14)
#1
La licence était encore très permissive, proche de l'open-source, mais contenait une clause empêchant les grands acteurs du cloud de l'utiliser ainsi sans acquérir une licence.
Car dans les faits, avec AWS (et d'autres presta cloud), ElasticSearch et Kibana étaient déployés à titre commercial par les fournisseurs infonuagiques, sans rien devoir reverser à l'éditeur. Les uns engrengaient une quantité exceptionnelle de revenus tandis que les autres rien. Et aucune contribution d"ordre financière pour aider à la vie du projet.
Le changement de licence de 2021 avait pour but de tenter de rééquilibrer un peu la donne.
La nouvelle licence ne pouvait pas être considérée comme open-source, car bien qu'offrant les 4 libertés, l'une d'elle (la distribution) était soumise à condition.
#1.1
#1.4
C'est devenu plus ou moins classique dans les projets open-sources. Par exemple, VLC le fait.
Avoir le droit sur les contributions permets de changer la licence du logiciel sans avoir à consulter tous les contributeurs. Exemple : passer de la GPL à la LGPL (ce qu'à fait VLC en 2011 je crois). C'était un travail titanesque, et le code introduit par des contributeurs qui n'ont pas répondu ou qui ont refusé a du être retiré du projet.
Avec la cession des droits, le changement de licence est beaucoup plus facile.
#1.2
À aucun moment une licence libre n'oblige à contribuer au projet. Je sais que moralement ça fait toujours grincer des dents, mais c'est, à mon sens, une vision qu'il faut toujours avoir quand on travaille un produit sous licence libre. Les gens sont libre de l'utiliser et de se faire du blé avec sans rien leur reverser.
J'avoue que ça m'étonne toujours ces cris de vierges effarouchées dans ce genre de situation. Le choix d'une licence n'est pas sans conséquence et ne doit jamais être fait à la légère !
Surtout de la part d'un éditeur de logiciel.
Historique des modifications :
Posté le 03/09/2024 à 10h31
Dudiable, avocat, enchanté.
À aucun moment la licence open source n'oblige à contribuer au projet. Je sais que moralement ça fait toujours grincer des dents, mais c'est, à mon sens, une vision qu'il faut toujours avoir quand on travaille un produit sous licence libre. Les gens sont libre de l'utiliser et de se faire du blé avec sans rien leur reverser.
J'avoue que ça m'étonne toujours ces cris de vierges effarouchées dans ce genre de situation. Le choix d'une licence n'est pas sans conséquence et ne doit jamais être fait à la légère !
Surtout de la part d'un éditeur de logiciel.
#1.3
Certains voudraient le beurre et l'argent du beurre : faire un produit libre (parce que le libre a bonne presse) ET obliger ceux qui l'utilisent à contribuer (directement ou financièrement).
Ben non, c'est pas comme ça que le libre fonctionne.
Le but de mon commentaire c'était de signaler que bien que le produit n'était plus sous licence libre, il n'était pas à source fermée pour autant. Le libre est très manichéen dans sa vision : on est libre ou on ne l'est pas. Il n'y a pas de "on est presque libre" (ce qui était le cas ici).
Historique des modifications :
Posté le 03/09/2024 à 11h36
C'est tout à fait ça cher confrère :) (je me fais souvent l'avocat du diable aussi).
Certains voudraient le beurre et l'argent du beurre : faire un produit libre (parce que le libre a bonne presse) ET obliger ceux qui l'utilisent à contribuer (directement ou financièrement).
Ben non, c'est pas comme ça que le libre fonctionne.
Le but de mon commentaire c'était de signaler que bien que le produit n'était plus sous licence libre, il n'était pas à source fermée pour autant. Le libre est trait manichéen dans sa vision : on est libre ou on ne l'est pas. Il n'y a pas de "on est presque libre" (ce qui était le cas ici).
#1.5
Pour appréhender plus facilement cette idée, il suffit de regarder du côté de Creative Commons. Dès qu'on applique des restrictions (NC / ND), la licence n'est plus considérée comme libre. Par contre l'oeuvre reste "ouverte".
#1.7
Même pas. D'un point de vue pratique "libre" = "open source" et partage les 4 libertés fondamentales. La différence se situe dans leur philosophie. L'open source répond à la question comment, le libre, à la question pourquoi.
Pour ma part, je serais bien partant pour un équivalent des licences CC pour le code. Car aujourd'hui, on a :
- libre ou open-source : respecte les 4 libertés fondamentales
- propriétaire ou privateur (on a les deux) : qui n'est pas libre / open-source
On commence à voir apparaitre depuis quelques années un entre deux, avec des licences dites source available, pour préciser qu'un projet n'est pas libre mais que les sources sont disponibles (cas justement d'ElasticSearch et de Kabana par exemple).
Les CC ne répondent pas forcément au besoin du code, car les termes de la CC peuvent être sujet à interprétation. Une clause comme non commercial peut revêtir plusieurs aspects qu'il est impératif de définir précisément.
Même ce problème de définition se rencontre régulièrement dans les licences logiciels libres.
Par exemple, la GPLv3 interdit la tivoïsation, ce que la GPLv2 autorise "par omission".
De même, l'AGPL vient préciser la notion d'utilisateur dans le cas du Web, là où en GPL le terme utilisateur reste très vague et très subjectif.
#1.9
N'est-ce pas un peu ce qu'essaye de faire Louis Rossmann / Futo avec le concept de source first ?
Historique des modifications :
Posté le 03/09/2024 à 22h29
« Pour ma part, je serais bien partant pour un équivalent des licences CC pour le code. »
N'est-ce pas un peu ce qu'essaye de faire Louis Rossmann / Futo avec le concept de source first ?
Posté le 03/09/2024 à 22h29
N'est-ce pas un peu ce qu'essaye de faire Louis Rossmann / Futo avec le concept de source first ?
#1.12
Par contre, sa licence pourrait s'intégrer dans un pack de licence, afin d'offrir plus de possibilité que simplement libre / pas libre.
Sa licence est intéressante sur plusieurs aspects, car elle va lutter un peu contre la merdification des logiciels, notamment :
- en interdisant la mise en place de publicité payante (par ex. Firefox ne pourrait l'être, car intègre de la publicité sur sa page d'accueil par défaut)
- en restreignant la télémétrie à de l'opt-out
- pas d'usage commercial
Elle permet également de soutenir, en théorie tout du moins, les éditeurs en obligeant les grandes entreprises à payer (c'est une des obligations).
Alors, cette licence n'est clairement pas libre, et reste malheureusement en l'état inutilisable pour moi. Pourquoi ? Simplement à cause de l'utilisation de notions trop floues, sans définition précise.
Exemples :
- qu'est-ce qu'un utilisateur ? A priori, avec le second paragraphe, un utilisateur serait celui qui exécute un logiciel sur son ordinateur, et excluerait donc du champ les utilisateurs de SAAS. Sauf que le no free ride for Megacorps va un peu à l'encontre de cette idée
- aucune définition de ce qu'est une grande organisation (nombre d'employés ? Nombre d'utilisateurs ? CA ? Disponibilité géographie ? ...)
- manque de clarté sur la notion de non-commercial. S'il n'y a pas trop de souci pour un site marchand, qu'en est-il pour un site vitrine d'une société ? Est-ce un usage commercial ou non ? Et si le service est fourni gratuitement, mais est inclus dans un pack payant (exemple : service d'hébergement web payant avec backup gratuit, la solution de backup étant sous Source First), est-ce un usage commercial ou non commercial ? ...
#1.6
Alors que la licence SSPL va plus loin, en obligeant à publier toute la stack logicielle utilisée pour fournir le service (outils de déploiement, d'administration, etc.)
Du coup, une double licence SSPL + commerciale permet de rester dans la philosophie du libre tout en forçant les AWS et consorts :
- soit à contribuer plus fortement encore au projet avec la publication de ces outils
- soit à prendre une licence commerciale auprès de l'éditeur (le plus probable, car publier leurs outils de déploiement et d'administration internes, ça serait donner tous les outils pour monter une offre concurrente)
Le souci, c'est que la licence n'est pas considérée comme libre par l'OSI, car elle est considérée comme trop discriminatoire (si j'ai bien compris, une boîte qui fournit du service managé en s'appuyant sur un soft sous SSPL modifié + des outils propriétaires fournis par un tiers pour l'administrer serait dans l'impossibilité de respecter la licence SSPL).
C'est dommage comme situation, car du coup, les projets libres ne profitent que très peu des revenus astronomiques du cloud. Mais remédier à cela tout en respectant à la lettre la compatibilité avec les licences libres paraît un problème inextricable (jusqu'à preuve du contraire)
Historique des modifications :
Posté le 03/09/2024 à 12h04
Et si je peux me permettre une précision sur la précision : la licence AGPL (reconnue comme libre par l'Open Source Initiative) permet de répondre à une partie de ce déséquilibre, en obligeant les fournisseurs cloud à publier les modifications qu'ils font sur le logiciel avec cette licence pour les services fournis en ligne pour leurs offres "as a service".
Alors que la licence SSPL va plus loin, en obligeant à publier toute la stack logicielle utilisée pour fournir le service (outils de déploiement, d'administration, etc.)
Du coup, une double licence SSPL + commerciale permet de rester dans la philosophie du libre tout en forçant les AWS et consorts :
- soit à contribuer plus fortement encore au projet avec la publication de ces outils
- soit à prendre une licence commerciale auprès de l'éditeur (le plus probable, car publier leurs outils de déploiement et d'administration internes, ça serait donner tous les outils pour monter une offre concurrente)
Le souci, c'est que la licence n'est pas considérée comme libre par l'OSI, car elle est considérée comme trop discriminatoire (une boîte qui fournit du service managé en s'appuyant sur des outils propriétaires fournis par un tiers ne peut pas utiliser le produit sous licence SSPL).
C'est dommage comme situation, car du coup, les projets libres ne profitent que très peu des revenus astronomiques du cloud. Mais remédier à cela tout en respectant à la lettre la compatibilité avec les licences libres paraît un problème inextricable (jusqu'à preuve du contraire)
#1.8
Du coup, j'apporte une précision sur la précision de la précision ;) La licence AGPL n'apporte pas d'obligation supplémentaire par rapport à la GPL en terme de diffusion et de droit sur les modifications. L'AGPL accorde les mêmes droits que la GPL aux utilisateurs.
La différence porte sur la notion d'utilisateur, notamment dans le cadre du Web (exemple typique : une appli SAAS) : un utilisateur (dans le cadre de la licence) est un utilisateur dans le sens de l'application. Du coup, si le logiciel est sous AGPL, l'utilisateur est en droit de demander l'accès au code source de la version qui lui ait proposée (c'est-à-dire avec les modifications de personnalisation dans le cadre d'AWS par exemple).
Car pour rappel, les licences libres / open-source s'adresse à l'utilisateur, c'est à dire celui qui reçoit le logiciel. Mais la notion de celui qui reçoit peut s'avérer flou dans certains cas (cas de la GPL pour le web), et c'est pourquoi des licences comme la AGPL ont vu le jour, afin de préciser cela.
Exemple avec Wordpress, un lecteur qui arrive sur un blog propulsé par Wordpress :
- avec la GPL (licence actuelle de Wordpress) : ne peut pas demander les sources (il n'est pas considéré comme un utilisateur au sens de la GPL)
- avec la AGPL : peut demander les sources (car il est considéré comme un utilisateur)
Le monde des licences, c'est un vrai casse-tête dès qu'on commence à creuser un peu.
#1.10
Et sur la raison qui fait que la licence SSPL n'est pas considérée comme libre, ma compréhension est la bonne, d'après toi ?
#1.11
#2
Historique des modifications :
Posté le 03/09/2024 à 12h08
Et si je peux me permettre une précision sur la précision de @fdorin : la licence AGPL (reconnue comme libre par l'Open Source Initiative) permet de répondre à une partie de ce déséquilibre, en obligeant les fournisseurs cloud à publier les modifications qu'ils font sur le logiciel avec cette licence pour les services fournis en ligne pour leurs offres "as a service".
Alors que la licence SSPL va plus loin, en obligeant à publier toute la stack logicielle utilisée pour fournir le service (outils de déploiement, d'administration, etc.)
Du coup, une double licence SSPL + commerciale permet de rester dans la philosophie du libre tout en forçant les AWS et consorts :
- soit à contribuer plus fortement encore au projet avec la publication de ces outils
- soit à prendre une licence commerciale auprès de l'éditeur (le plus probable, car publier leurs outils de déploiement et d'administration internes, ça serait donner tous les outils pour monter une offre concurrente)
Le souci, c'est que la licence n'est pas considérée comme libre par l'OSI, car elle est considérée comme trop discriminatoire (une boîte qui fournit du service managé en s'appuyant sur des outils propriétaires fournis par un tiers ne peut pas utiliser le produit sous licence SSPL).
C'est dommage comme situation, car du coup, les projets libres ne profitent que très peu des revenus astronomiques du cloud. Mais remédier à cela tout en respectant à la lettre la compatibilité avec les licences libres paraît un problème inextricable (jusqu'à preuve du contraire)